home *** CD-ROM | disk | FTP | other *** search
/ Univers Mac Interactif 42 / Univers Mac Interactif - Issue 42.iso / Internet / MacHTTP 2.0 / MacHTTP Software & Docs / Documentation / Release_Notes2.txt < prev    next >
Text File  |  1994-12-18  |  23KB  |  461 lines
  1. Release Notes for MacHTTP 2.0 (part 2)
  2.  
  3. Version 1.3.1b16 additions
  4. ------------------------
  5. + Fixed the Power Mac password dialog bug.
  6.  
  7. + Fixed the conflict between caching servers (or clients) and password security
  8. checks. MacHTTP now demands a password for secure documents if a correct one
  9. isn't supplied with the request, even if the client or caching server already has
  10. the current copy of the document.
  11.  
  12.  
  13. Version 1.3.1b15 additions
  14. ------------------------
  15. + Check memory allocation at start-up. MacHTTP now estimates how much memory you
  16. will need as it starts up, based on your config file settings. It will complain
  17. if you don't give it enough memory, but will launch and run as long as the barest
  18. minimums are available (32k).
  19.  
  20. If memory requirements change during runtime (i.e. the upcoming AppleEvents for
  21. adjusting MAX_USERS, etc.), you will be responsible for ensuring that MacHTTP
  22. already has enough memory to accomodate the change.
  23.  
  24. + Support for caching proxy servers. MacHTTP now works properly with caching
  25. proxy servers that send the "If-Modified-Since" tag in the request. If the
  26. modification date of the requested file has not changed, MacHTTP returns a "304
  27. Not Modified" header, rather than sending the complete file. Note that MacHTTP
  28. logs zero bytes transfered in this case. This is NOT a bug.
  29.  
  30. + Authentication by folder, multiple realms, username & password support. This is
  31. the BIG change for b15, so read the following carefully!!! MacHTTP now FULLY
  32. supports the Basic authentication scheme for all files it serves. This means that
  33. you may control access down to individual files and assign usernames and
  34. passwords.
  35.  
  36. How authentication works:
  37.   The Basic authentication scheme is built into most WWW clients (older versions
  38. of MacWeb and Mosaic do not support authentication). Authentication is OPTIONAL
  39. and you may choose not to activate any password-based security on your server.
  40. When a file or folder is restricted to access by certain users, MacHTTP returns a
  41. result to WWW clients that forces them to prompt the user for a username and
  42. password to access the file. Assuming the username and password sent to MacHTTP
  43. from the client are valid, the requested file is returned. Future requests for
  44. files requiring the same permissions will cause the WWW client to send the
  45. username and password automatically. Normally, this means a user will only have
  46. to enter a password once for convenience purposes.
  47.  
  48. How MacHTTP implements authentication:
  49.   MacHTTP allows you to divide your files and folders into multiple security
  50. "realms." Files and folders are placed in a realm, based on the text of the URL
  51. to the specific file. For example, suppose you want to configure your server so
  52. that you have some files available to everyone, some files availalble to
  53. co-workers, and some files available to customers. 
  54.  
  55. The MacHTTP.config file adds a new command, "REALM", which allows you to do this.
  56.  The syntax of the REALM command is:
  57.  
  58. REALM <match_string> <descriptive_name>
  59.  
  60. where match_string represents some substring of a URL that will be unique to all
  61. files in that realm and descriptive_name is text (no spaces!) that describes the
  62. realm in human readable terms. The arguments to REALM are case insensitive.
  63.  
  64. Back to the example, assume your config file contains the following lines:
  65.  
  66. REALM work Co-Workers
  67. REALM cust Customers
  68.  
  69. Files in the Co-Workers realm may have names like:
  70. http://your.host/working_draft.html
  71. http://your.host/work-info/staff_photo.gif
  72. http://your.host/personnel/workers_comp.html
  73.  
  74. Customer files may look like:
  75. http://your.host/customer_data/price_list.html
  76. http://your.host/custom_designs.html
  77.  
  78. Using the "Co-Worker" example, MacHTTP looks for the match_string "work" in a
  79. URL. If it sees it, it requires authentication from the WWW client before it will
  80. allow access to the file. Notice that the substring "work" can be part of the
  81. file name, or a folder containing the file. MacHTTP will find the substring
  82. anywhere in the URL, so you can control access to multiple files by placing them
  83. in a folder whose name contains a realm's match_string. Be careful not to have a
  84. single URL match two realms. If this happens, MacHTTP uses the first realm that
  85. matches, in the order that they are entered in the config file.
  86.  
  87. Once it has found that a file requires authentication, MacHTTP sends the
  88. appropriate message to the WWW client and passes the descriptive_name (in this
  89. case "Co-Workers") to the client. The WWW client will show this string to the
  90. user when it prompts the user for a username and password. MacHTTP will use a
  91. combination of the username and the realm to look up the correct password from
  92. the new "MacHTTP Settings" file. If the password supplied by the user matches the
  93. password found in the settings file, the file will be returned to the user.
  94.  
  95. The MacHTTP Settings file:
  96.   This file is where username and password information is stored for all users
  97. authorized to access restricted files on your server. The information is stored
  98. as STRing resources, so there is no possibility that a remote user can download
  99. this information from your server. Ultimately, many of MacHTTP's settings and
  100. configuration information stored in the MacHTTP.config file will move to the new
  101. settings file. For the time being, there will be one more file to clutter up your
  102. MacHTTP folder.
  103.  
  104. Creating Passwords:
  105.   Assuming that there is at least one REALM statement in your MacHTTP.config
  106. file, you can use the new "Passwords..." menu command under the "Edit" menu to
  107. add or delete password entries from the MacHTTP Settings file. (Ultimately, there
  108. will be balloon help and AppleGuide info for this dialog.) To add a new username,
  109. enter the name in the "User Name" field, the password in the "Password" field,
  110. and use the "Realms" pop-up menu to select a security realm from those defined in
  111. the config file. Then, click the Add button. The new username will appear in the
  112. scrolling list, along with the realm it is assigned to.  Note that a user name
  113. may be entered in multiple realms, allowing the user to be both a co-worker and a
  114. customer, for example. Each username/realm combination must be unique within the
  115. settings file.
  116.  
  117. To view a username's password or to delete a username, select one of the names
  118. from the scrolling list. The information comprising the username entry will be
  119. displayed in the username and password fields and the realm pop-up. Press the
  120. Delete button to remove the username. Although you may modify the values in the
  121. fields at this point, if you press the Add button, the changes will be saved as a
  122. new username and will not modify the old entry. To modify an existing username,
  123. delete the old one and add a new one.
  124.  
  125. Usernames are available immediately after adding them, so there is no need to
  126. stop or start the server. In addition, MacHTTP will continue to serve files while
  127. you are entering username info.
  128.  
  129. This is a major new chunk of functionality and I am interested in any and all
  130. feedback regarding its behavior.
  131.  
  132. Version 1.3.1b14 additions
  133. ------------------------
  134. + added ACGI type for asynchronous CGI apps and scripts and returned CGI type to
  135. its old synchronous behavior. ACGI files will behave as CGI files did under
  136. b11-b13. CGI files will behave as they did under b10 and earlier.
  137.  
  138. + increased POST arg size to 8k.
  139.  
  140. + b14 is now a fat binary again, built with CodeWarrior.
  141.  
  142. Version 1.3.1b13 additions
  143. ------------------------
  144. + Fixed mystery crash from b11, b12. This should eliminate unexplained type 1 and
  145. type 2 errors.
  146.  
  147. + Added Date: and Last-Modified: fields to headers returned by MacHTTP. This
  148. allows MacHTTP to work with caching servers. Note that the Date: and
  149. Last-Modified: fields are only returned for TEXT and BINARY documents. SCRIPT,
  150. APPL, and CGI applications are all responsible for generating these headers
  151. themselves, if necessary. (In most cases, these dates will always be the current
  152. date and time, since CGIs are generating new HTML each execution.)
  153.  
  154. Version 1.3.1b12 additions
  155. ------------------------
  156. + This version is essentially unchanged from b11, with the exception of a few
  157. more error checks that may help eliminate the random crashes some users
  158. experience.
  159.  
  160. + Parse username and password from authentication field (completed)
  161.    MacHTTP now correctly parses the username and password from a "user" type
  162. authentication message as sent by WWW clients using the "Basic" authentication
  163. scheme. The "Authorization:" tag is sent by clients in response to a HTTP "401"
  164. status code. A demonstration script is included that shows how to prompt the user
  165. for a password and use the results to grant access. Examine "password.cgi" for
  166. details.
  167.  
  168. This feature works with current versions of Mac Mosaic ONLY. MacWeb support is
  169. coming soon, according to the author. 
  170.  
  171. Check the following URL for complete details on authentication:
  172. http://info.cern.ch/hypertext/WWW/AccessAuthorization/Overview.html
  173.  
  174. Version 1.3.1b11 additions
  175. ------------------------
  176. + asynch AppleEvents
  177.    MacHTTP now sends AppleEvents to CGI applications immediately, without waiting
  178. for a reply. When the application completes and returns results to MacHTTP's
  179. event queue, the results are passed on to the WWW client. This allows multiple
  180. scripts to run at the same time without MacHTTP having to wait until each one
  181. completes. Clients requesting TEXT or BINARY files are no longer forced to wait
  182. for CGI requests to complete.
  183.  
  184. IMPORTANT!!! You should NOT write applications that quit immediately after
  185. serving a single request. If you do, you run the risk of accidently discarding a
  186. pending AppleEvent that MacHTTP has placed in your event queue. Rather, you
  187. should only quit when there are no more pending AppleEvents (i.e., you've
  188. received an Idle event.)
  189.  
  190. + Unlimited suffix mappings
  191.   MacHTTP should now support an unlimited number of suffix mappings.
  192. Unfortunately, MacHTTP no longer provides default mappings if it cannot find a
  193. config file.
  194.  
  195. + add args to SCRIPT files
  196.   SCRIPT type files are now passed the same arguments as CGI files. Predefined
  197. variables include:
  198. path_args
  199. http_search_args
  200. post_args
  201. method
  202. client_address
  203. username
  204. password
  205.  
  206. Note that the http_request variable is no longer available.
  207.  
  208. + Parse username and password from authentication field
  209.    MacHTTP now parses the username and password from a "user" type authentication
  210. message as sent by WWW clients. This feature has not been tested with current WWW
  211. clients. The "Authorization:" tag is sent by clients in response to a HTTP "401"
  212. status code. I've been unable to get a script to successfully bring up the
  213. authentication dialog on Mosaic or MacWeb. If anyone can demonstrate this feature
  214. in operation, please send me the script!
  215.  
  216. Version 1.3.1b10 additions
  217. ------------------------
  218. + Fixed the "defunct listens" bug introduced in b8.
  219.  
  220. Version 1.3.1b9 additions
  221. -----------------------
  222. + increased default stack space for 68000 Macs. This needs to be tested by a
  223. 68000 Mac user as I don't have access to one. It *should* allow MacHTTP to run on
  224. all Macs now.
  225.  
  226. + completed work on POST method. POST arguments are now extracted from the
  227. client's query based on the size transmitted in the query, eliminating trailing
  228. CR/LFs from the post args passed to scripts.
  229.  
  230. + fixed the "-1 connections" bug.
  231.  
  232. + added Content-Length to the HTTP/1.0 header. This means that clients will now
  233. be able to display how much data is being sent from MacHTTP for TEXT and BINARY
  234. files.
  235.  
  236. + fixed the order of "/" translations in URLs. MacHTTP now converts "/" to ":",
  237. translates %xx encodings, then converts "::" to ":". Steps 1 and 2 were
  238. previously reversed, making "/" illegal in file names.
  239.  
  240. + added security by DNS name. As of version 1.3.1b9 you may also specify full or
  241. partial domain names for ALLOW and DENY statements. The domain names are matched
  242. from right to left, as opposed to the left to right matches done for IP address
  243. ALLOW and DENY statements. Also, the domain names you specify are case-sensitive
  244. and MUST end with a period (.).
  245. For example:
  246.   ALLOW tmc.edu.
  247.   DENY oac.hsc.uth.tmc.edu.
  248. would deny all hosts (implicit DENY *), allow any tmc.edu node, and deny the
  249. specific host, oac.hsc.uth.tmc.edu.
  250.  
  251. Version 1.3.1b8 additions
  252. -----------------------
  253. First, B8 is NOT a fat binary. B8 adds several new features, including the long
  254. awaited POST method. Please note that several aspects of the user interface are
  255. in the process of changing. For instance, the bar graph will probably replace the
  256. numeric connection information, a zoom box will be added, a server stats window
  257. will be added etc.
  258.  
  259. + added check for A/UX and a possible fix for rapid phantom connections
  260. This *may* solve the problem that A/UX users have reported with repeated phantom
  261. connections. If you run A/UX, PLEASE try this version out and let me know how it
  262. works.
  263.  
  264. + add POST method
  265. The POST method is now supported (where appropriate). CGI routines can receive
  266. their arguments via a POST method in addition to the GET method. This means forms
  267. can use the GET or POST method.
  268.  
  269. Using the POST method:
  270. ---------------------
  271. Using the POST method is as simple as changing the method used by your HTML form
  272. documents from GET to POST. MacHTTP now passes two additional AppleEvent
  273. parameters to CGI scripts and applications. They are "post arguments" (keyword
  274. 'post') and the "method" (keyword 'meth'). The sample script that comes with this
  275. archive demonstrates the new syntax for these additional arguments. 
  276.  
  277. Normally, if POST arguments are passed, the search arguments and path arguments
  278. will probably be empty. However, you can create URLs for the "submit" button on
  279. forms that do pass path and/or search args. This could allow a single script to
  280. handle multiple forms, for example. Check the "method" parameter to determine
  281. whether or not the POST arguments are valid. They are only valid if the method is
  282. "POST" (duh.)
  283.  
  284. MacHTTP does NOT translate special characters that may be embedded in post
  285. arguments (unlike search args passed by GET methods). Currently, POST arguments
  286. are limited to 2048 bytes. This limit will be removed in the final version,
  287. allowing post arguments of arbitrary size. I just want to make sure the logic
  288. works now before adding a bunch of dynamic memory allocation.
  289.  
  290. + add additional CGI args to AppleEvents (method, request header, POST args,
  291. etc.)
  292. See above. Added 'post' and 'meth' AppleEvent keywords. Both are strings.
  293.  
  294. + make main window resizeable
  295. Still need to add a zoom box and remember window positions, but resizing seems to
  296. work OK. 
  297.  
  298. + remove %xx translation from args sent to scripts
  299. See above. POST arguments are not translated. Search and Path args still have %xx
  300. encoded characters and '+' chars translated.
  301.  
  302.  
  303. Version 1.3.1b7 additions
  304. -----------------------
  305. This version is unchanged from b6 with one IMPORTANT exception. MacHTTP 1.3.1b7
  306. is NOT a fat binary. It is 680x0 code only. This is because there is a very HUGE
  307. bug in the ANSI libraries that ship with CodeWarrior. Until this bug is fixed,
  308. MacHTTP will be built using Think C only. In short, CodeWarrior's standard I/O
  309. routines cannot read (correctly) using two streams that access the same read-only
  310. file. Since this happens all the time with MacHTTP, it's unacceptable and would
  311. require a very large modification to MacHTTP's internal logic to avoid.
  312.  
  313. Version 1.3.1b6 additions
  314. -----------------------
  315. + added support for default file in each folder.
  316. IMPORTANT!!! You MUST change your config file entry for the INDEX file to remove
  317. any leading directory information before the file name (including even ":"). This
  318. config file entry is now the file that will be returned whenever a directory is
  319. requested as a URL, regardless of the directory. This allows you to put a
  320. "default.html" file in every directory that will be returned when clients request
  321. a directory instead of a file. Again, it should be a simple file name like
  322. "default.html", not a full or partial path name like ":default.html".
  323.  
  324. Note that if a malformed directory URL  (i.e., a URL without a trailing "/") is
  325. requested, MacHTTP considers this an error and returns the error file instead of
  326. the index file. This is to avoid confusing some clients that still don't deal
  327. with malformed directory requests.
  328.  
  329. + fixed special file returns to include correct MIME types
  330. Requesting directories, non-existent files, etc. will no longer result in sending
  331. an "empty screen" to some clients. A MIME type is always returned.
  332.  
  333. + fixed data overruns on path and search args
  334. This was probably the cause of many of the mysterious crashes. If path or search
  335. args were too long, they were overwriting data. MacHTTP now checks for args that
  336. are too long and simply truncates them. A warning is also written to the screen.
  337.  
  338. + added start-up time stamp to screen and AppleEvent Status Report.
  339.  
  340. + added MacHTTP version info to AppleEvent Status Report.
  341.  
  342. Version 1.3.1b5 additions
  343. -----------------------
  344. The "DNS Bug" has been fixed. The 68k portion of the fat binary was built using
  345. an incorrect version of the DNR.c source file, causing it to work improperly.
  346.  
  347. The problem with Error.html being returned with the wrong MIME type has been
  348. fixed (sort of). As long as your ERROR file is a HTML file, the correct MIME
  349. type will be returned to the client, regardless of the type or name of the file
  350. the client was originally requesting. Previously, GIFs, etc. that weren't 
  351. found resulted in the client receiving a HTML error message file that had
  352. a GIF MIME type.
  353.  
  354. A minor modification was made to the way MacHTTP writes to the log file.
  355. Previous versions of MacHTTP flushed the output buffer for the log file after
  356. every message was written to the log. This causes a lot of unnecessary disk
  357. I/O and may be the root of the problem with large log files. The downside is
  358. that the log file *may* not yet contain the most recent few log entries if you 
  359. try opening an active log file with another application. PLEASE let me know if 
  360. this modification improves MacHTTP's behavior with large log files or if it
  361. causes problems because log entries are buffered.
  362.  
  363. Version 1.3.1b4 additions
  364. -----------------------
  365. This beta is a fat binary. It is built entirely with CodeWarrior DR/3. It *may*
  366. correct problems with large log files since it is using CodeWarrior libraries
  367. instead of Think C I/O routines. I would appreciate hearing any feedback
  368. on whether or not this problem "goes away".
  369.  
  370. Version 1.3.1b4 adds support for improved DNS performance. A new config file
  371. directive, "NO_DNS", has been added. If you add a single line to the config file:
  372. NO_DNS
  373. MacHTTP will avoid accessing the domain name service, improving performance.
  374. The drawback is that MacHTTP will only log IP addresses rather than the host
  375. name. Use this option if you have a flakey DNS, lots of clients that don't
  376. support
  377. reverse look-ups, or other DNS problems.
  378.  
  379. 1.3.1b4 also improves DNS caching if you leave DNS services enabled. MacHTTP
  380. will cache the last few name look-ups, minimizing the need for DNS look-ups
  381. but maintaining the host names while logging.
  382.  
  383. Version 1.3.1b1 additions
  384. -----------------------
  385.  
  386. Version 1.3.1b1 of MacHTTP is unchanged from 1.3 with the exception of the 
  387. introduction of a single new feature. This beta adds support for sending a new
  388. AppleEvent, called "Search Doc," to script applications or stand-alone programs.
  389. The "Search Doc" event is sent whenever a client requests a URL which has a
  390. suffix mapping of a new type, "CGI."
  391.  
  392. The CGI suffix mapping and the Search Doc event give MacHTTP a superset of the
  393. capabilities available in Unix servers using the common gateway interface (CGI)
  394. standard for interfacing to external programs. In the final version of MacHTTP
  395. 1.3.1, CGI applications will be passed the following information whenever a
  396. client requests the application's URL:
  397.  
  398. • path arguments:     the "path arguments" portion of a URL, used to pass
  399. arguments to the CGI application in addition to the search arguments.
  400.  
  401. • search arguments:  this is the same data from "http_search_args" we've all come
  402. to know and love.
  403.  
  404. • address:  This is the domain name of the WWW client requesting the URL.
  405.  
  406. • user name: The user name passed by the WWW client in the Authorization: tag of
  407. the HTTP request. (not passed by 1.3.1b1 yet)
  408.  
  409. • password: The password passed by the WWW client in the Authorization: tag of
  410. the HTTP request. (not passed by 1.3.1b1 yet)
  411.  
  412. The syntax for the CGI suffix mapping in the config file is identical to the
  413. other suffix mappings. See the config file for an example. The CGI file type
  414. behaves exactly the same as the APPL file type, with the exception of the
  415. additional parameters passed besides  "search arguments."
  416.  
  417. New URL Syntax
  418. --------------
  419. This info is subject to change, but for now, the syntax of URLs understood by
  420. MacHTTP looks like:
  421. <protocol> // [<host>]/<path> [$<path args>] [?<search args>]
  422.  
  423. Notice that "$" has been added to the syntax to divide path arguments from the
  424. actual path to the searching application and the search arguments. This is legal
  425. syntax according to the URL standard, but using "$" to represent path arguments
  426. isn't explicitly part of the URL standard and isn't the way CGI URLs are
  427. specified for Unix servers. Therefore, the syntax MAY change in the future.
  428.  
  429. An example of a URL using this syntax might be:
  430. http://your.host.edu/search.cgi$document_1.data?some+search+terms
  431.  
  432. Semantically, this might be interpreted as follows. MacHTTP will launch the
  433. application "search.cgi." It will pass it everything after $ and before ? as path
  434. arguments. The text after ? is passed as search arguments. The path arguments can
  435. mean ANYTHING to the application. In this case, they may tell the application
  436. which document to search (i.e., document_1.data). As long as there are no spaces,
  437. you can put up to 512 bytes of path arguments after the $.
  438.  
  439. The Search Example application available from the Examples page on the MacHTTP
  440. Home Page includes support for handling the new "Search Doc" event. AppleScripts
  441. should add handlers for the WWWΩsdoc event (as opposed to the old WWWΩsrch
  442. event). 
  443. A sample AppleScript for handling the "Search Doc" event is included in this
  444. archive.
  445.  
  446. The AETE resource (AppleScript dictionary) entries for this new event look like:
  447.  
  448. Search Doc: Search a specific document for keywords
  449.     Search Doc  'char'  -- Path Arguments
  450.         for  'char'  -- Search arguments 
  451.         [address  'char']  -- Client Address
  452.         [user  'char']  -- User Name
  453.         [password  'char']  -- Password
  454.     Result:   'char'  -- Search Results
  455.  
  456. To test the new CGI/Search Doc functions, place a copy of the Search.exe
  457. application from the "Search Example" archive mentioned above in the MacHTTP
  458. folder. Rename it to "Search.cgi." Make a copy of the "search_me" data file and
  459. place it in the same folder as "Search.cgi". Access it using the URL:
  460. http://your.host.edu/Search.cgi$search_me?two
  461.